One or more aspects relate to the field of publish/subscribe messaging. In particular, one or more aspects relate to publish/subscribe messaging using a message structure.
There are many situations in which the user of a computer system may want one application or system to share certain information with another application or system. For example, it would be useful if, when composing a new email in a client such as Notes (Notes is a trademark of International Business Machines Corporation), the client could collect email addresses seen on screens in other applications; for example, a colleague may have just sent the address of someone in Sametime (Sametime is a trademark of International Business Machines Corporation). Currently, the user has to copy and paste this address from Sametime to Notes.
For a simple case of one-to-one linking between two applications, or even many-to-one linking, this can be accomplished easily using inter-process communication, or having the receiving application expose an application programming interface (API) of some kind, such that it can listen for input of a certain pre-defined form. However, this system becomes unmanageable when there are many-to-many links, and when there is no precise pre-agreed standard for the form of information required. For example, there are many regular expressions in use to validate email addresses.
To solve this problem, as well as potentially others, publish/subscribe and queue-based messaging systems may be used. Publish/subscribe messaging systems are very popular, but one requirement is that the topic name is known in order to publish and subscribe to messages.
Two applications may communicate by publishing and then subscribing to an agreed topic, but this would require the developers of the two applications to agree on a topic name. Often, naming schemes and conventions are agreed upon in standards, but occasionally one may desire to publish or subscribe to ad-hoc topics.